POV-Ray : Newsgroups : povray.programming : cleaning source code from warnings troubles : Re: cleaning source code from warnings troubles Server Time
28 Jul 2024 08:35:12 EDT (-0400)
  Re: cleaning source code from warnings troubles  
From: Thorsten Froehlich
Date: 1 Oct 2002 07:31:28
Message: <3d998790$1@news.povray.org>
In article <3d9980e2$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> 1) generates less warning messages and thus

It only generates warnings on broken compilers.  If the compiler you use is
broken, the solution is to switch to a compiler which is not broken or to
workaround the broken compiler by disabling the particular warning by hand.

> 2) is less likely to fail.
<snip>
> As to the second... Thorsten, believe it or not, compiler writers are not
> idiots. Not all of them. There ARE cases when simple multi-character
> constants would not work, while #defines or similar means would rectify the
> situation...

No, this is nonsense.  They do work as specified everywhere!

Your example is yet again one of those reading data from disk misuse cases.
Maybe you do not understand that "implementation defined" is exactly what
you show?  It does not even have to work when using two compilers on the
same platform.  An "implementation" is a single compiler on a single
platform.

Maybe you have not noticed, but POV-Ray neither reads nor writes
multicharacter constants.  It does not because that behavior is
implementation defined.  So there is absolutely nothing wrong and nothing
that can ever break anywhere either.

>   unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
>   fprintf(outfile," %lu", prog);
>   ...
>   fscanf(infile," %lu",&prog);
>   if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }
>
> This code would work ACROSS MOST platforms. While alternative (your)
> approach would fail if files are to be transferred between e.g. PCs and old
> Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
> some EBCDIC-based dinosaur, we still can just modify the macro definition
> accordingly, not every piece of code dealing with constants. So the code is
> MORE portable and thus BETTER. Please note: not "absolutely portable and
> thus the BEST", but still worth trying.

I am not really sure if I should be upset or offended by such ignorance as
this issue has already been discussed and explained well in this thread.
Please read the whole thread first before repeating something already
discussed.  If you don't want to read the whole thread, please stop adding
noise to the discussion.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.